Nora Sandler's favorite deep dives into systems (and system failures) for curious programmers

Before I read this book, I knew a bunch of facts about the different pieces of computer systems. After I read it, I understood how those pieces fit together. Building all those pieces myself, starting from the simplest logic gates and working my way up, made some fundamental concepts finally click—like how a processor decodes an instruction.

I especially loved the book’s hands-on structure: each chapter is a project where you get a specification and test suite for the component you need to build, but you have to figure out exactly how to build it for yourself. Completing the projects often felt like solving a fun puzzle, and it made the concepts stick in a way that just reading about them wouldn’t have.

One of the best ways to understand how software works is to study how it fails. When I was just starting my career in software security, I read this book to learn about binary exploits like buffer overflows. It’s been a long time since I’ve written a binary exploit, but digging into the nitty-gritty, low-level details of how software runs on a real system has helped with everything I’ve done as an engineer since.

A lot has changed since this book was published in 2008 (and running the accompanying Live CD has gotten trickier), but the fundamental concepts are as relevant as ever.

This isn’t a technical book, but it gets to the heart of why so much software is fragile and insecure. This book examines spectacular failures of all sorts, from nuclear meltdowns to plane crashes to oil spills, but I loved it because its message resonated with my own experience writing and debugging code. It argues that complex, tightly coupled systems involving hidden interactions and close coordination between lots of different parts are more likely to fail catastrophically. It also talks about strategies to make those systems safer, like doing “premortems,” getting advice from outsiders, and building diverse teams.

My big takeaway? Technical solutions alone won’t make software (or other complex systems) safer. We need to change how we build and how our organizations work, too.

Although I don’t work in government, this is a book I’ll come back to whenever I need a reminder to put user needs ahead of process or wisdom about how to work inside a large bureaucracy to make that happen. Where Meltdown focuses on spectacular blow-ups, this book explores run-of-the-mill failures—like long, complicated online forms and websites that only load in specific, outdated browsers. (Though bigger failures, like the launch of healthcare.gov, get airtime too.)

I appreciated this book’s thoughtful analysis of how government software gets built—it goes beyond the stereotype of the incompetent government employee and digs into the underlying reasons that even competent and dedicated public servants can struggle to deliver critical software. Many of those reasons apply to private companies, too. 

This book gave me a new framework for thinking about how political change happens and how technology shapes our society. It analyzes how social media platforms like Facebook have helped antiauthoritarian movements achieve dazzling success almost overnight—and how those platforms have weakened and endangered those same movements. I loved that this book was clear and readable without oversimplifying the topic. It showed—as Tufecki writes, quoting another scholar—that “technology is neither good nor bad; nor is it neutral.”

This isn’t exactly a book about computer systems, but I decided to include it because it gave me a deeper understanding of how technological and social systems influence each other—which I hope will change how I write software myself.